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Description 

Field of the invention 

[0001] The present invention is related to billing sys- 5 
terns for billing custcnners, In particular prepay custom- 
ers for mobile/cellular telecom services. 

State of the art 

10 

[0002] With the existing emerging new services such 
as Web originated SMS, WAP services and m-com- 
merce, all accessed using cellular phones, billing of 
services becomes more and more complex. Further, a 
lot of services are only available to so-called postpaid is 
customers, i.e. subscription customers, and tariffs for a 
specific service may be subscription-specific (e.g. free 
for high-end subscribers, paying for low-end subscrib- 
ers). This usually leads to development of a different ar- 
chitecture per service to cope with these differences, as 
the content provider usually is not aware of the custom- 
er's privileges. 

[0003] New ways of paying for products and services 
via mobile telecommunication means are currently be- 
ing Introduced. Products Include for example drinks ob- 25 
tainable from a distributor in a public place, while serv- 
ices can be e.g. parking space or movie tickets. Also so- 
called mobile banking will be available soon. These sys- 
tems rely on a subscriber account, which can be used 
to pay for products and/or services by using a cellular 30 
phone. 

The prior art document W098/21 874 describes a sys- 
tem for revaluing via a central network system prepaid 
cards used by prepaid type customers of or mobile net- 
work. Such prior art system is shown in the boxes 35,37 
in figure 4, detailed In the sequel. 

Problem Definition and aim of the Invention 

[0004] Cun^entiy, there Is no available architecture 
that can handle all these services, and there is no archi- 
tecture available that enables alt these services in a 
transparent way for post- and prepaid customers. Fur- 
thermore, it should also be possible to settle a balance 
which may be due by the content provider to the tele- 
communication service provider 
[0005] The present invention aims to provide an ar- 
chitecture for the service provider which realises pay- 
ments and billing of content provided to a customer, in- 
dependent of the type of customer (postpaid or prepaid), 
the platfomn or the content itself. 

Summary of the Invention 

[0006] In a first aspect of the present invention a serv- 
ice mediator system is disclosed, the service mediator 
system being implementable on a computer environ- 
ment and being arranged for delivering services to a 



customer of a company having at least two types of cus- 
tomers with different billing data, said system further be- 
ing arranged for delivering said services or confirming 
said service for delivery only after verification of said bill- 
ing data. Said services can optionally include the deter- 
mination of the location of said customer. The detemii- 
nation of the location of a customer can also be done 
through an additional module that Is connected to or part 
of the service mediator system and that is further linked 
to a communication system such as telecommunication 
system, for instance a GSM or GPRS or UMTS or any 
cellular network, or a GPS/GLONASS system. Said 
services can be taken from or be provided by a third par- 
ty and be forwarded by said system to said customer. 
Said system can bill the customer separately from de- 
livering said services to said customer. The services can 
In such case be payment confimnation messages fol- 
lowed by the signalling of predetermined events such 
as goals In a socker game. 

[0007] In a preferred embodiment of this first aspect 
of the present invention, said services can be content 
data being delivered by a third party content provider 
and the company can be a mobile telecommuhications 
operator company. In such case, or also in other cases, 
as an option said content data can be selected depend- 
ing upon the location position of the customer. For ex- 
ample a customer can request through his mobile ter- 
minal infomaation about traffic or about a restaurant lo- 
cation in the same area (or even region) to a content 
services company. Through the location service of the 
mobile telecommunications operator the location of the 
customer is fonvarded to the content services company, 
and based on that location inf onnatlon, the content serv- 
ices company will forward the location or area or region- 
al specific data, such as the specific location dependent 
traffic or restaurant information. 
[0008] Content data such as location data can also be 
sent from the customer to the third party content provid- 
er. 

[0009] In* a second aspect of the present invention, a 
service mediator system is disclosed, the system being 
implementable on a computer environment and being 
arranged for receiving via mobile communication tech- 
niques content from a content provider and being ad- 
dressed to a customer, the system being arranged for 
verifying the customer's billing data, and for forwarding 
or confirming to the content provider the approval for de- 
livery or refusing a transaction of the content to the cus- 
tomer based on the customer's billing data. 
[0010] According to the first and second and further 
aspects of the present invention, the customer's billing 
data comprise data about the type of customer (prepaid 
or postpaid), and/or data about the account of said cus- 
tomer, and/or data about the subscriber account of said 
customer. The content service can be any kind of exist- 
ing or future service that can be obtained with a mobile 
telephone. Preferably the services are different from re- 
valuing the amount on a prepaid card used by a custom- 
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er for accessing or mobile network via a mobile tele- 
phone. This Includes SMS, Web-orlglnated SMS, WAP, 
l-Mode, banking services, credit services, on-site pay- 
ment for sen/ices (e.g. parking lot) or products (e.g. 
drinks dispenser). The content service furthermore can 
Include information about the weather forecast, traffic 
infomiatlon. horoscope predictions, sweepstake Infor- 
mation, flight information, financial and exchanges in- 
fomnation, cultural and social events, nightlife in a city, 
etc. The servk^e provider system of the invention can be 
used for any mobile communications technology such 
as UMTS, GSM, WAP, l-Mode GPRS, or any future mo- 
bile communications technology, and making use of any 
protocol such as XML or mobile html or UCP or other 
protocols. The content can be requested by the custom- 
er to the telecom service provider, possibly via the serv- 
ice mediator system, or can be requested by the cus- 
tomer directly from the content provider, possibly via the 
telecommunications network of the telecom service pro- 
vider. The content can also be delivered by the content 
provider to the customer without a request of the cus- 
tomer or can be delivered on a regular basis based on 
a first request for content from the customer. 
[0011] In a third aspect of the present invention, a 
servk^e provider system for providing content services 
to a mobile communteations customer is disclosed, said 
system comprising: 

• a telecom services provider system wherein or 
wherethrough a link is provided to a content provid- 
er system, and 

• a service mediator system, 

and wherein said service mediator system Is 
arranged to 

• receive said content from said content provider, 

• allow or refuse or confirm the transaction to the cus- 
tomer based on the customer's billing data, 

• and optionally, in case of allowance, provide said 
content service to the customer, and optionally 

• bill said customer for the content. 

[001 2] The content sen^ice can be any kind of existing 
or future service that can be obtained with a mobile tel- 
ephone. This includes SMS, Web-originated SMS, 
WAP, i-Mode, banking services, credit sen/ices, on-site 
payment for services (e.g. parking lot) or products (e.g. 
drinks dispenser). The content service furthermore can 
include information about the weather forecast, traffic 
infonnation, horoscope predictions, sweepstake infor- 
mation, flight information, financial and exchanges in- 
fonnation, cultural and social events, nightlife In a city, 
etc. The servtee provider system of the invention can be 
used for any mobile communications technology such 
as UMTS, GSM, WAP, i-Mode, GPRS, or any other and/ 
or future mobile communications technology, and mak- 
ing use of any protocol such as XML or mobile html or 
UCP or other protocols. 

[001 3] The content can be requ ested by the customer 



to the telecom sen^lce provider, possibly via the service 
mediator system (SMS or web based), or preferably can 
be requested by the customer directly from the content 
providers, possibly via the telecommunications network 

s of the telecom sen/ice provider. The content can also be 
delivered by the content provider to the customer with- 
out a request of the customer or can be delivered on a 
regular basis based on a first request for content from 
the customer (push messages). 

10 [0014] Preferably, the system according to this third 
aspect of the present Invention is at least partly Imple- 
mented on a computer environment. 
[001 5] The servtee provider system according to this 
third aspect of the present invention can be further ar- 

is ranged in that said service mediator comprises a pay- 
ment/billing server arranged to perfomi validation of the 
customer's request and payment and/or billing for the 
content service. This payment/billing server is prefera- 
bly a database, comprising customer data such as type 

20 of customer: (postpaid or prepaid); subscriber accounts: 
billing infonmation (for postpaid customers) and prepaid 
account Information (for prepaid customers). Thus the 
term billing data is to be understood as comprising data 
about the type of customer (postpaid or prepaid)and 

25 about the actual prepaid balance or the account Infor- 
mation of the customer. 

[0016] In a fourth aspect of the present invention, a 
method for providing content services to a mobile com- 
munications customer is disclosed, said method com- 
30 prising the following steps: 



• receiving a customer request for a content service 
by a content provider, optionally comprising the step 
of receiving the customer request for the content 
sen/ice by a mediator and transferring it to the con- 
tent provider, 

• delivering said content service to a service media- 
tor, the service mediator optionally being the same 
as said mediator, 
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wherein said service mediatorperfomns the follow- 
ing steps: 

• allowing or refusing of the transaction to the cus- 
tomer based on the customer's billing data, 

• in case of allowance, providing said content service 
to the customer or confimiing approval for delivery 
to the content provider, and optionally 

• billing said customer and/or content provider for the 
content. 



[0017] The method can be further characterised In 
that the customer's billing data comprises data about the 
type of customer (prepaid or postpaid), data about the 
55 accou nt of said customer, and optionally data about the 
subscriber account of said customer. 
[0018] In case the customer Is a prepaid customer, 
said step of billing said customer can comprise wlth- 
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drawal of the required sum from the customer's account. 
[001 9] The customer can also be a postpaid custom- 
er. The method of the present Invention can be further 
characterised In that said step of billing said customer 
comprises withdrawal of the required sum from an m- s 
commerce account. 

[0020] In a preferred embodiment, the method further 
comprises the step of billing the customer for the trans- 
port of the content. 

[0021] The present invention thus provides a reliable 
and economically efficient method and system for deliv- 
ering content services to mobile subscribers. The mo- 
bile subscribers may be both prepaid and postpaid sub- 
scribers. Also, using the present system and method it 
is possible for a telecommunication service provider to is 
settle balances due by the content provider, e.g. for us- 
ing the service mediator functionality. 
[0022] The different aspects and embodiments of the 
Invention as described hereabove or in the detailed de- 
scription can be combined according to the knowledge 20 
of the person of skill In the art as reading this patent text. 

Short description of the drawings 

[0023] 

Fig. 1 and 2 represent an example of a system ac- 
cording to the present invention and illustrate the 
method of the invention. 

Figure 3 shows a flow diagram of the present meth- so 
od. 

Figure 4 shows a detailed architecture of the archi- 
tecture of a service mediator system according to a 
best mode embodiment of the present invention. 
Figure 5 shows a further embodiment of the present 3s 
system, In which location information Is used. 

Detailed description of the Invention 

[0024] For the purpose of teaching of the invention, 
preferred embodiments of the method and systems of 
the invention are described in the sequel. It will be ap- 
parent to the person skilled In the art that other alterna- 
tive and equivalent embodiments of the Invention can 
be conceived and reduced to practice without departing 
from the true spirit of the Invention, the scope of the in- 
vention being limited only by the appended claims as 
finally granted. 

Example 1: content billing of SMS via UCP 

[0025] Figure 1 describes the method of the present 
invention in the specific case of SMS billing. A customer 
20 sends in a request for a content service, in this case 
an SMS message 1 . This message is sent by the tele- 
com sen/Ice provider 22 to a content provider 23. This 
content provider 23 reacts to the message by sending 
the desired content to the service mediator 24 via mes- 



sage 2. The service mediator 24 will check whether the 
customer Is entitled to the content service. If allowable, 
the content Is sent to the customer using links 4,5. The 
Payment/Billing server 27 takes care of charging the 
customer's prepaid account, or sends an SDR (Servkie 
Detail Record) to the Telecom Service Provider's billing 
sen/ices to include the content service on the next bill 
for the postpaid customer. It is an option to Include the 
converters 25, 26 which transfomn UCP messages to 
XML messages and vice versa Into the service mediator 
module, as this allows for a unified standard language 
within the sen/ice mediator/paymentA)llling server mod- 
ule such as XML, and is also usefulto deal with requests 
In different languages, as these requests will be trans- 
lated by the converters 25, 26. 

Example 2: content billing of WAP 

[0026] Figure 2 describes the method of the present 
invention In the specific case of WAP services. Here 
again the request for a content service, a WAP request 
In this case, is sent to a content provider's site (CP Site) 
23 via WML message link 6, These requests are direct 
and the customer 20 can select the information he 
needs by browsing the site of the content provider 23, 
or change content provider 23 when he does not find 
the Information he needs. A request for a paying content 
service will transfer the customer 20 to a payment portal 
site 28 using WML message link 7. The payment portal 
site 28 receives data from the content provider 23(e.g. 
amount, transaction identification number and content- 
provider code)via WML message link 8. The customer 
20 will be authenticated at the payment portal site 28 
and is requested to confinn the payment via link 7 or via 
another WML-link. When the customer agrees, the pay- 
ment/billing server will be queried to check whether tlie 
customer is entitled to the service via XML link 9, con- 
verter 26 and XML link to the Service Mediator 24. If the 
answer Is affirmative, the payment will be effected as 
described higher and the content provider 23 will receh/e 
a confirmation of the payment via WML message link 
1 0. The customer will be redirected to the content pro- 
vider's site to receive the requested content services via 
WML message link 6. 

[0027] It Is clear that the method and the system of 
the present invention can be easily adapted to other 
content services than those illustrated by the figures and 
examples. More particularly SMS, Web-originated 
SMS, UMTS, WAP, i-Mode banking services, credit 
services, on-site payment for services (e.g. parking lot) 
or products (e.g. drinks dispenser), ... are easily imple- 
mentable using a single architecture. Also subscriber 
accounts can be charged using the method of the Inven- 
tion, internal accounts (i.e. accounts that reside at the 
Telecom Service Provider) as well as external accounts 
(e.g. banks, credit card companies). 
[0028] The Sen/ice Mediator 24 has as a goal to deal 
with providing the content service to the customer and 
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with the payment issues. The Payment/billing server 27 
allows to query customer data and effectuates the pay* 
ment. 

[0029] Preferably, the telecom transport costs for pro- 
viding the service are billed separately. This can easily 
be implemented using a tariffing server. This Is neces- 
sary because not all traffic generated by the content re- 
quest will be normal traffic, billable by the telecom serv- 
ice provider but can be e.g. internet traffic. 
[0030] It Is also possible to settle the costs for the con- 
tent provider by the telecommunication provider (pay- 
ment/billing server), possibly with inclusion of costs pay- 
able by the content provider to the telecommunication 
provider. 

[0031] Fig. 3 shows a flow diagram of an embodiment 
of the present method as implemented for delivery by 
the service mediator of SMS messages from a content 
provider 23. The flow can be divided In two interrelated 
parts, the Service Switching Function (SSF) and the 
Service Control Function (SCF). The SSF part receives 
a message of the provider at block 40 and searches for 
the data which are necessary to properly process the 
message In an administrative manner. These data are 
sent to the SCF. The switch Control Function first checks 
whether the customer is a prepaid subscriber at decision 
biocl< 50. if the customer is a prepaid subscriber, the 
balance value is lool<ed op in block 51 and in decision 
block 52, it is checked whether the balance is sufficient. 
If sufficient balance is present, a *GO' message is sent 
to the SSF (block 54). If insufficient balance is present, 
a 'NOGO* message is sent to the SSF (block 53) and 
the SCF flow Is ended. In the meantime, the SSF func- 
tion has waited for a response from the SCF in block 41 . 
In decision block 42, the response is checked. When the 
response Is negative (NOGO), a negative acknowledge- 
ment (NACK) is sent to the provider in block 43 and the 
flow of the SSF ends. When the response is positive 
(GO), the message is converted and sent to an SMS 
centre in block 44. After that, the SSF function will wait 
for a response from the SMS centre In block 45, and 
after receiving the response, this response of the SMS 
centre is sent to the SCF in block 46. When the response 
from the SMS centre is positive (check in decision block 
47), a positive acknowledgement (ACK) is sent to the 
provider in block 48 after which the flow ends. When the 
response from the SMS centre is negative (check in de- 
cision block 47), a negative acknowledgement (NACK) 
is sent to the provider in block 49 after which the flow 
ends. When the SCF receives the response of the SMS 
centre (after waiting In block 55) it checks in decision 
block 56 whether the response is positive, if the re- 
sponse is negative, the flow of the SCF ends. If the re- 
sponse is positive, it is again checked in decision block 
57 whether the customer is a prepaid customer. If this 
Is the case, the balance Is decreased with the proper 
amount In block 58. When the customer is a postpaid 
subscriber, the flow directly continues to block 59, in 
whteh a call detail record (CDR Is written to the SMI, 



after which the flow ends. Thus, the amount for the serv- 
ice will only be charged when the message transaction 
has actually taken place. 

5 Best Mode Embodiment 

[0032] In a best mode embodiment of the invention, 
as depicted in Fig. 4, a service mediator system that Is 
implemented for a mobile telecommunications operator 

10 and that Is on the basis of a Message Broker software 
module is described. In the existing situation, the con- 
tent provider 23 communicates directly with the custom- 
er 20 via the SMS centre 33, as indicated by arrow 30. 
The Message Broker can be any one of the commerclal- 

is ly available message broker products of major software 
companies. An example can be the Impact product of 
the company Sybase (NEON). The message broker is 
split in a protocol layer 31 and a message broker layer 

33. The message broker layer 32 Is connected to a SM- 
20 Sc module 33 and to the Operational Data Store of the 

customers database (ODS) 34, and to the Prepaid Bill- 
ing System 35. The protocol layer 31 is arranged for 
communication with a content provider system 23 and 
can communicate therewith via a UCP or a XML proto- 
ns col. The protocol layer 31 and message broker layer 32 
can communicate among them via a fast internal proto- 
col. The message broker layer 32 can communicate with 
the SMSc module 33 via UCP protocol and to the Op- 
erational Data Store of the customers database (ODS) 
30 34 via LDAP (Lightweight Directory Access Protocol) 
protocol, and to the Prepaid Billing System 35 via a XML 
protocol. The message broker layer 32 can in a further 
embodiment also communicate with a location base 
server 36 using a suitable protocol. The SMS centre 33, 
35 the Operational Data Store of the customers database 
(ODS) 34, the prepaid billing system 35, and the location 
base server 36 can also communicate with a back- 
ground server 37 of the telecommunication service pro- 
vider. The background server 37 Is an^a':g&ci a.o. to con- 
40 trol and update the other elements of the present sys- 
tem. 

[0033] The service mediator 24 can check the status 
of the customer by querying the Operational Data Store 

34. Using the MSISDN number of the customer 20 
45 (country code, telecom provider code and serial 

number, e.g. 31653123456) as input, the Operational 
Data Store will respond with the status of the customer 
(prepaid, postpaid, none and blocked flags). When the 
Operational Data Store 34 responds with the status 

50 'none', that particular customer is not a subscriber of the 
telecommunication provider operating the service me- 
diator 24. It is also possible, that a known subscriber will 
be blocked from certain services for a number of rea- 
sons. This situation will be Indk^ated by the Operational 

55 Data Store 34 using the blocked flags. 

[0034] In Fig. 5. a schematic diagram is shown In 
which use can be made of location infomnation of the 
customer for providing Infomnation by a content provider 
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23. A customer 20, using a cellular phone, contacts a 
content provider 23 to indicate that local Infonnation Is 
needed. The content provider 23 forwards this request 
to the service mediator 24. as discussed earlier. The 
service nnediator 24 may send a request for location in- 5 
fomnation of a customer to a location base server 36, e. 
g. by using the MSISDN number of the customer as a 
reference. The location base server (LBS) 36 receives 
inf onmation on the present location of the customer 20, 
e.g. using Infomnation of the cellular networl< (transceiv- io 
ers 38, location database 39). Next, the service media- 
tor 24 receives the co-ordinates (X,Y) of the associated 
customer and fonvards this to the content provider 23. 
When it is checked that the content provider can supply 
proper local Information, the content provider 23 will is 
send the infomiation to the service mediator 24 which 
will forward the content as described earlier to the cus- 
tomer 20. The service mediator 24 will send an acknowl- 
edgement to the content provider 23, if the customer 
could be billed. 20 
[0035] The infonnatlon provided by the content pro- 
vider 23 may Include Infomiation requested instantane- 
ously by the customer 20, periodic infomnation, such as 
traffic information, or event generated information, such 
as a stock value crossing a preset threshold. 25 
[0036] As described with reference to Fig. 4, the serv- 
ice mediator 24 may provide a UCP51 or XML interface 
for the content providers 23. Other messages will be re- 
plied to with an error message or ignored (unknown 
messages). 30 
[0037] In a UCP51 type message, a tariff field may be 
included (preferably in the XSER field), which indicates 
the tariff the content provider 23 wants to charge for that 
specific service to the customer 20. The service media- 
tor 24 will parse the received messages, by checking 35 
the type of message, the LEN field in the header and 
the checksum of the UCP message. After this, the serv- 
ice mediator 24 will remove the tariff field from the UCP 
message and send the UCP message onward (e.g. to 
the SMS centre 33). In this way, the service mediator 24 40 
is a transparent system for the content provider 23 with 
respect to UCP messages (with the exception of the tar- 
iff field. 

[0038] The service mediator 24 will manage a provid- 
er profile file, in which it is indicated what actions are 
allowed for a specific content provider 23. This may re- 
late to a specific interface which may be used by a spe- 
cific content provider 23 (such as UCP, XML single des- 
tination or XML multiple destination), or to a specific 
function provided by the service mediator. The number so 
of allowed functions for a content provider 23 may be 
equal to zero, thereby effectively blocking that content 
provider 23. 

[0039] The service mediator is able to notify a sub- 
scriber (customer) when a message can not be deliv- ss 
ered for some reason, such as too little funds on the pre- 
paid account. Preferably, the text which is sent to the 
customer is dependent on the originating content pro- 
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vider. This function of the service mediator 24 can also 
be disabled for a specify content provider 23. In that 
case, it Is assumed that the content provider 23 self will 
infomri the customer. 

[0040] Also, in the provider profile, a maximum 
amount for a service can be set for each provider. When 
the service mediator 24 receives a message in which 
the tariff as Indicated is higher than the maximum 
amount for that content provider, the service mediator 
24 will not accept the message (and inform the sender 
of the message using an error code in the response 
message). 

[0041] The service mediator 24 will also check the 
length of a message. In case of an alphanumeric mes- 
sage, the maximum number of characters in the mes- 
sage is 1 60. When it is larger, the message will not be 
accepted. Transparent messages are already limited to 
140 characters and this will not conflk:t with further sys- 
tem requirements. For transparent messages, no check 
on length is necessary. 

[0042] The throughput for each content provider 23 Is 
measured by the service mediator 23. When a preset 
maximum Is crossed for a certain content provider 23 
(as stored in the provider profile) the throughput of that 
content provider will be limited by delaying the response 
to a message (ACK/NACK). The maximum throughput 
is defined as X messages in Y seconds. 
[0043] In order to be able to control peak loads more 
efficiently, the service mediator 23 can define one or 
more time slots, in which a predetermined content pro- 
vider 23 has access or no access to the system. This 
access time window function is relevant for a limited 
number of content providers 23 which have high 
throughput values. For 'small' content providers 23 this 
function is not relevant, and this can be indicated in the 
provider profile. The time window function can be Imple- 
mented on the TCP/IP connection level. In that case, 
the sen/ice mediator 24 must be able to disconnect the 
TCP/IP connection to the specific content provider 23. 
[0044] To be able to control the throughput of a con- 
tent provider 23 it Is also possible to set the maximum 
number of parallel connections for each content provid- 
er 23 in the provider profile. When a content provider 23 
wants to open additional sessions, the service mediator 
24 will ignore these messages and send an error code 
to the content provider 23. 

[0045] The service mediator 24 will log various data 
concerning the processing of the transactions in log 
files. A number of generic requirements are set for the 
)og files, i.e. starting time, maximum time that file is 
open, maximum size of the log file and manual closing 
of a log file to allow an operator to Inspect the log file. 
As the service mediator 24 may be implemented In a 
parallel manner, i.e. a number of servers may run the 
service mediator functionality, the log files of each serv- 
er may be copied periodically to a central logging server. 
It Is also possible to post-process the log files, e.g. for 
data reduction or system analysis. 
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Claims 

1. A service mediator system Imptementable on a 
computer environment and being arranged for de- 
livering services to a customer of a company having 
at least two types of customers with different billing 
data, said system further being an-anged for deliv- 
ering said services or confirming said service deliv- 
ery only after verification of said billing data. 

2. The system as recited in claim 1 wherein said serv- 
ices include the detemilnation of the location of said 
customer. 

3. The system as recited in claim 1 wherein said serv- 
ices are taken from a third party and fonvarded by 
said system to said customer. 

4. The system as recited In claim 3 wherein said serv- 
ices are content data being delivered by a third party 
content provider, and wherein as an option said 
content data are selected depending upon the loca- 
tion position of the customer. 

5. The system as recited in claim 1 wherein said cus- 
tomer is billed separately from delivering said serv- 
ices to said customer 

6. The system as recited in claim 1 , wherein the cus- 
tomer's bliilng data comprises data about the type 
of customer (prepaid or postpaid), and/or data 
about the subscriber account of said customer. 

7. A service mediator system implementabie on a 
computer environment and being arranged for re- 
ceiving via mobile communication techniques con- 
tent from a content provider and being addressed 
to a customer, for verifying the customer's billing da- 
ta, and for forwarding or confirming said content for 
delivery or refusing a transaction of the content to 
the customer based on the customer's billing data. 

8. System as recited In claim 7, wherein the custom- 
er's billing data comprises data about the type of 
customer (prepaid or postpaid), and/or data about 
the subscriber account of said customer. 

9. A service provider system for providing content 
services to a mobile communications customer, 
said system comprising: 

• a telecom services provider system wherein a 
ilnic is provided to a content provider system, 
and 

• a service mediator module, 

wherein said service mediator module is ar- 
ranged to 
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• receive said content from said content provider, 

• allow or refuse or conflnm the transaction based 
on the customer's billing data, 

• and optionally, In case of allowance, provide 
said content service to the customer. 

10. The service provider system as recited in claim 9 
wherein the service mediator is further arranged to 
bill said customer for the content and for the use of 
the telecom provider system. 

1 1 . Service provider system as In claim 1 0, wherein the 
system is at least partly implemented on a computer 
environment. 

12. Service provider system as in claim 1 1 , wherein said 
service mediator comprises a payment/billing serv- 
er arranged to perform validation of the customer's 
request and payment and/or billing for the content 
service. 

13. The service provider system as recited In claim 9 
wherein a module Is Included for detennining the 
location of said customer, the content possibly be- 
ing dependent on the actual location of said cus- 
tomer. 



14. Method for providing content services to a mobile 
communications customer, comprising the follow- 
ing steps: 

• receiving a customer request for a content serv- 
ice by a content provider, 

• delivering said content service to a service me- 
diator, 

and wherein said service mediator per- 
fomns the following steps: 

• allowing or refusing or confirming of the trans- 
action based on the customer's billing data, 

• optionally, In case of allowance, providing said 
content service to the customer, and optionally 

• billing said customer and/or content provider 
for the content. 

15. Method as in claim 14, further wherein the custom- 
er's billing data comprises data about the type of 
customer (prepaid or postpaid), data about the ac- 
count of said customer, and optionally data about 
the subscriber account of said customer. 

16. Method as in claim 14 wherein the customer is a 
prepaid customer. 

S5 17. Method as in claim 1 6, wherein said step of billing 
said customer comprises withdrawal of the required 
sum from the customer's account. 
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IB. Method as In claim 14 wherein the customer Is a 
postpaid customer. 

19. Method as In claim 14, wherein that said step of bill- 
ing said customer comprises withdrawal of the re- 5 
quired sum from an subscriber account. 

20. Method as In any of claims 14. further comprising 
the step of billing the customer and/or content pro- 
vider for the transport of the content. io 
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